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Claims 

[d] Knowledge-Driven Architecture is a software architecture 
comprising: 

(a) Knowledgebase containing business rules and ap- 
plication scenarios that reflect application require- 
ments 

(b) Application Scenario Player capable of playing 
scenarios and transforming acts of scenarios and 
business rules into interactions with knowledgebase, 
presentation components, and the underlying appli- 
cation services 

(c) Service Connector 

(d) Presenter components 

(e) Service components 

(f) Optimizer 

(g) Methods enabling: 

(i) separation of software in the application layer, 
which describes interactions and service calls, and 
the system layer, which describes services 

(ii) storage of application layer description that re- 
flects application requirements as business rules 
and scenarios in the knowledgebase 



(iii) interpretation of scenarios and business rules 
into interactions with knowledgebase, presentation 
components, and the underlying application ser- 
vices 

(iv) creation and modification of business rules and 
scenarios that comprise the application layer at 
run-time 

(v) invocation of services designed as integration- 
ready components with differentiated APIs 

(vi) translation of snapshots of existing rules and 
scenarios into source code of a traditional fixed- 
form application with better performance and less 
flexibility 

(vii) analysis of successful scenario execution in- 
cluding: 

a) history of successes 

b) history of interpretation failures 

c) learning scenarios that prompt an agent (a user 
or a program) to re-define the input or to provide 
more details for better interpretation 

d) queue of scenarios with un-answered ques- 
tions to resolve unsuccessful interpretations 

(viii) ability to exchange information about knowl- 



edge and service elements existing on other dis- 
tributed network systems built with this architec- 
ture 

(ix) multiple forms of knowledge and service re- 
source sharing over distributed networks 

[c2] Knowledge-driven architecture of claim 1 wherein appli- 
cation scenarios are written with the Application Scenario 
Language that allows developers or business experts to 
quickly build the software application layer by describing 
application flow as a set of scenarios that define interac- 
tions between system components and agents, where 
said agents can be users, human beings, or programs, 
for example, a partner program engaged in a common 
business transaction. 

[c3] Knowledge-driven architecture of claim 2 wherein appli- 
cation scenarios consist of scenario acts that can define: 

(a) interactions between system components and 
agents 

(b) prompt messages to agents, expected agent re- 
sponses, if any, and rules for interpretation of agent 
responses 

(c) invocations of knowledgebase services, like 
queries, assertions, etc. using service names and op- 
tional arguments 



(d) invocations of application services using service 
and operation names and optional arguments 

(e) variables that are replaced with their values at 
run-time 

(f) conditions based on run-time variable values and 
knowledgebase queries 

(g) the order of execution of scenarios and scenario 
acts 

(h) aliases, or multiple ways of expressing the same 
meaning 

(i) translation policies related to input 

(j) possible agent events and event handling rules 
(k) instructions for presentation components 

Knowledge-driven architecture of claim 1 wherein the 
Presenter can include 

(a) Formatter that prepares data for audio or video 
interaction or for communication to other programs 

(b) Communicator that provides formatted data com- 
munications via peer-to-peer distributed networks or 
any other protocols 

(c) Performer that uses formatted data for actual pre- 
sentation via voice or screen 

(d) special engines such as speech, handwriting, or 
image recognition, which might target a specific type 
of user input 



[c5] Knowledge-driven architecture of claim 1 wherein the 
knowledgebase component includes a Knowledge Service 
component 

[c6] Knowledge-driven architecture of claim 5 wherein the 
Knowledge Service component serves as an adapter to the 
knowledgebase, adapting the knowledge engine inter- 
face to the interface required by the Service Connector 

[c7] Knowledge-driven architecture of claim 1 wherein the 
Service Connector component includes: 

(a) Object Retrieval that is able to find an existing 
service object or load the requested service class and 
instantiate the object at run-time 

(b) Object Registry that associates service objects 
with service and object names, stores service objects, 
and makes them reusable 

(c) Method Retrieval that retrieves the proper service 
method belonging to a selected service object based 
on the provided method arguments 

(d) Method Performer that performs the requested 
service operation on the selected service object 

[c8] Knowledge-driven architecture of claim 1 wherein the 

Optimizer takes a snapshot of existing rules and scenar- 
ios and translates them into source code in a language 



such as Java or C#, which can later be compiled into bi- 
nary code to fix the current application rules into a regu- 
lar application that lacks flexibility but provides better 
performance. 

Knowledge-driven architecture of claim 1 wherein the 
Scenario Player contains but is not limited to: 

(a) Input Type Checker that checks current input and, 
depending on its type, submits the input to one of 
several interpreters 

(b) One or more interpreters, such as the Scenario 
Act Interpreter, the Prompt Response Interpreter, the 
New Agent Request Interpreter, etc. that, based on 
scenario and knowledgebase rules, translate acts of 
scenarios or any other input into a direct action by 
one of the system components 

(c) Queue of Scenarios that stores the current sce- 
nario when it cannot be executed at the current time, 
but needs to be executed later 

(d) Success Analysis component that can store and 
retreive a history of interpretation successes and fail- 
ures, and in the case of interpretation failure invokes 
one of several learning scenarios that prompt an 
agent (a user or a program) to re-define the input or 
to provide more details for a better interpretation 



[do] Knowledge-driven architecture of claim 1 wherein ser- 
vice components are endowed with usage and value 
properties. 

[d 1] Knowledge-driven architecture of claim 9 wherein the 
Success Analysis component maintains and consistently 
refines a list of previously used services with their APIs, 
keywords, descriptions, and related scenarios in the 
knowledgebase, and re-evaluates the usage and value 
properties of the services. 

[d2] Knowledge-driven architecture of claim 9 wherein the 

New Agent Request interpreter uses the list of previously 
used services with their APIs, keywords, descriptions, 
and related scenarios for automatic translation of user 
requests into service APIs and scenario acts. 

[d3] Knowledge-driven architecture of claim 9 wherein the 
New Agent Request interpreter uses a list of previously 
used services with their APIs, keywords, descriptions, 
and related scenarios to offer selected parts of this in- 
formation to the user for semi-automatic translation of 
new requests into service APIs and scenario acts. 

[d4] Knowledge-driven architecture of claim 1 wherein the 
Communicator provides collaborative access to knowl- 
edge and services existing on other distributed network 



systems built with this architecture. 

[d5] Knowledge-driven architecture of claim 11 wherein the 
Success Analysis component propagates via the Commu- 
nicator to distributed network systems information on a 
new service API or a new knowledge subject after the 
first success operation that included the service or the 
knowledge subject and then after each update provided 
locally by the Success Analysis component. 

[d6] Knowledge-driven architecture of claim 15, wherein in- 
formation on new elements is propagated after the first 
successful operation that included the new element, and 
thereafter after each local update of such information by 
the Success Analysis component. 



